Web-based content application services (e.g., web services) and platforms (e.g., cloud computing platforms) have become ubiquitous. One benefit of using such application services and platforms is the ability to securely share content among trusted collaborators on a variety of user devices such as mobile phones, tablets, laptop computers, desktop computers, and/or other devices from any geographic location. To facilitate such flexible “always on” access, certain cloud-based shared content management platforms might provide various user applications in a distributed computing environment. For example, one or more applications might be provided to enable users to manage content, permissions, collaborators, and more. In many of these cases, a decision needs to be made as to where (e.g., which application server in which physical location) the code components that deliver the application functionality should be situated for execution. For example, some code components might be deployed as “in-process” code components to run in the same process (e.g., thread) as the application core logic, while other code components might be deployed as “out-of-process” code components to run in their own process separate from the application process (e.g., in middleware or in a back-end, etc.). In some cases, in-process code components can provide faster response times than that of out-of-process code components, however such an implementation might require that multiple instances of the in-process code components be maintained across multiple application servers. In other cases, the nature of the data accesses and computations might indicate that the code components should be in, or remain situated in, a remote location (e.g., in middleware or in a back-end computing environment). Orchestrating the communications between applications and out-of-process code components can add operational complexities, however such complexities might be acceptable in the context of the specific, then-current characteristics pertaining to the data accesses and computations to be performed. Any of a wide range of data accesses, computations, network communications, and related performance metrics can be relevant to code component deployment decisions.
Unfortunately, application developers (e.g., from a cloud-based content management provider) might not know with sufficient certainty how various applications and/or associated code components will be used, and/or under what environmental constraints might be present. This problem in assessing the technology available to a user at some future moment in time hinders making code component deployment decisions that will yield the highest performance at such a future moment in time. Often, application usage patterns vary over time, resulting in changing use models and/or changing environments and possible degradation of performance for a certain code component deployment (e.g., combination of in-process and out-of-process code components).
Legacy approaches that deploy code components in a predetermined allocation to components in a distributed computing environment are therefore deficient at least in their ability to address the uncertainty in code component usage as it relates to performance. For example, a code component servicing requests for queries related to enterprise operations may have been deployed as an out-of-process code component when the mix of enterprise users was small, however as the mix of enterprise users increases, the inherent workloads demanded by such additional enterprise users can contribute to degradation of system performance.
What is needed is a technique or techniques to improve over legacy approaches.